Generally, the present application relates to data processing. More specifically, the application is related to techniques for managing sessions in an access management system.
Modern businesses rely on a variety of applications and systems that control and generate information that is critical to business operations. Different applications often provide different services and information, and different users may require access to different levels of information within each system or application. The level of access that users are granted may depend on the role of the user. For example, a manager may need access to certain information about employees that report to him, but it may be improper for that manager to access the same information about those whom he reports to.
Earlier less sophisticated applications incorporated access management business logic directly into the application code. That is to say, each application would require users to have a separate account, separate policy logic, and separate permissions, for example. Furthermore, when a user is authenticated by one of these applications, this authentication remains unknown to other applications in the enterprise because the fact that authentication with the first application has taken place is not shared. Thus, there is no concept of trust between applications using different systems for authentication and access control. Engineers quickly realized that having an access management system for each application in an enterprise was much like having a gas station for each car, and determined that authentication and access control would be more efficiently implemented and managed as a shared resource. These shared resources became known as an access management systems.
Access management systems often use policies and other business logic to make a determination regarding whether a particular access request should be granted to a particular resource. Upon making a determination that access should be granted, a token is provided to a client (e.g., client application at a device) of the requestor. This token is like a key that can be used to open a door that guards restricted data. For example, a user may attempt to access a human resources database to gather information about certain employees such as salary information. The user's web browser at a client makes a request to the application, which requires authentication. If the web browser does not have a token, the user is asked to log in to the access management system. When the user is authenticated, the user's browser at the client receives a token that may be used to access the human resources application.
In an enterprise, users (e.g., employees) typically may have access to one or more different systems and applications. Each of these systems and applications may utilize different access control policies and require different credentials (e.g., user names and passwords). A user wanting to access multiple resources protected by an access management system may need to be authenticated by credentials provided to the access management system. A successful authentication gives the user authorization to access the protected resources, based on their assigned access privileges.
Upon authentication, the access management system may establish a session (“user session”) to provide the access granted to the protected resource(s). For a user session, the access management system may maintain session information at a computing system (e.g., server computer) for the user session. The session information maintained by access management system may be referred to as a server-side session. The access management system may store session information for the server-side session that defines the access granted to the user and the constraints of the session. The session information for a server-side session may be mapped to a client which is provided with a token. In the instance where a SSO session is established, the access management system enforces access for SSO based on the token.
If a user wants to access multiple resources protected the access management system, the access management system may determine whether the user is authenticated to access the multiple resources requested by a user. In some instances, authentication of a user for one resource may suffice for accessing other resources, otherwise the access management system may request additional credentials from the user. Upon authentication to access multiple resources, the user may not need to re-authenticate to access additional resources. In such instances, the access management system may maintain a single session, such as a single sign-on session (SSO), that provides a user with access to multiple resources after authentication.
Some access management systems may utilize different storage techniques to manage (e.g., create, read, update, or delete operations) session information for a session. Session information may include information about the user and the user session for which the user is authenticated. Managing session information may include accessing an identity store to query information about user. However, once information is accessed from the identity store, the access management system may not need to access the information for subsequent accesses by the user for the session. An access management system may incur performance overhead from repeated access to the identity store for information that rarely changes.
After authentication of a user to establish a session, an access management system may update session information for subsequent accesses to a resource. Subsequent accesses may result in determining authorization and/or performing additional authentication (e.g., step-up authentication), either of which cause session information to be updated.
Updating session information may cause significant performance and/or memory usage overhead. For example, an access management system implemented by a computing system having multiple computing nodes, may implement locking techniques, such as distributed locking, to permit session information to be updated, even if the update is a timestamp. In some instances, distributed account locking may be performed to update session information. The locking technique may cause the access management system to encounter performance issues to implement locking where storage is shared in a distributed fashion. Based on the number of attributes and the group memberships that are stored for a user in an identity store, each session belonging to specific user may be duplicated for the session. If a user's status changes in an identity store, each of the sessions needs to be identified and deactivated to enable the sessions to be updated. In some instances, session aggregation and updates may be performed across computing nodes of an access management system.
Where distribute cache is implemented to store session information, the session information may be evicted from memory and serialized to a backend session database based on cache eviction policy. Updating session information that is currently serialized to a database can cause huge performance overhead for the access management system. In some instances, even when different storage techniques are implemented, session information may be replicated for multiple sessions that exist for a user on multiple clients. Memory may need to be optimized on a per session basis, thereby contributing to memory usage overhead to maintain session information.